Proposal for Prebid.js Enforcement of Device Access

[bretg]

(followup to #4701)

Proposal for Prebid.js Enforcement of Device Access

Objectives

• Prebid.js should by be able to enforce a rule that header bidding activity cannot access the user’s device for storing data in the appropriate regulatory environments.
• Publishers and Managed Service providers should have fine-grained control over which parts of Prebid can and cannot access and store data on the user’s device.

Assumptions

• PBJS will not load the IAB Global Vendor List (GVL) - that would be too expensive and affect the results of the header bidding auction.
• LocalStorage and Cookies are considered the same for the purposes of this feature. When ‘accessing the device’ is mentioned, it refers to both LocalStorage and Cookies.
• In the future, Prebid.js (and Prebid Server) may have the capability of filtering bidders from the auction that do not support GDPR, COPPA, US-Privacy, etc, but for now publishers must manage the bidder list themselves.

Scenarios

Scenario	4.0 Result	3.x Result
The CMP tells PBJS that the user is in GDPR scope but has not provided a consent string.	PBJS should prevent header bidding activity from accessing the device.	PBJS allows usersyncs from all configured vendors and userId modules to initiate, trusting that each will do the right thing with respect to GDPR.
The CMP tells PBJS that the user is in GDPR scope and they have provided a consent string that grants Purpose 1 access globally.	PBJS should allow header bidding activity to access the device.	(as above)
The CMP tells PBJS that the user is in GDPR scope and they have provided a consent string that denies Purpose 1 access globally.	PBJS should prevent header bidding activity from accessing the device.	(as above)
The CMP tells PBJS that the user is in GDPR scope and they have provided a consent string that denies Purpose 1 access globally, but allows Purpose 1 for Vendor V.	PBJS should prevent header bidding activity from accessing the device except for Vendor V.	(as above)
The CMP tells PBJS that the user is in GDPR scope but has not provided a consent string, and the publisher has defined a default configuration that allows device access and that their parameters take precedence.	PBJS should allow header bidding activity to access the device.	(as above)
The CMP tells PBJS that the user is in GDPR scope and they have provided a consent string that allows Purpose 1 access globally but denies access for Vendor V. The publisher has overridden the configuration to allow Vendor V, but has not defined the priority order of configuration.	PBJS should allow header bidding activity to access the device except for Vendor V.	(as above)
The CMP tells PBJS that the user is in GDPR scope and they have provided a consent string that allows Purpose 1 access globally but denies access for Vendor V. The publisher has overridden the configuration to allow Vendor V, and has defined that their configuration takes priority over the GDPR string.	PBJS should allow header bidding activity to access the device including Vendor V.	(as above)
The CMP tells PBJS that the user is in GDPR scope and they have provided a consent string that denies Purpose 1 access globally. The Publisher has overridden the configuration to allow Vendor V and UserID module U to allow device access as per their privacy policy.	PBJS should prevent header bidding activity from accessing the device except for Vendor V and UserId Module U.	(as above)
The Publisher has set the COPPA flag.	PBJS should prevent header bidding activity from accessing the device.	(as above)
The Publisher has set the COPPA flag and overriding parameters to allow UserID module U to allow device access.	PBJS should prevent header bidding activity from accessing the device except for UserId Module U.	(as above)
The Publisher decides for whatever reason that this user's device should not be accessed. (e.g. for content aimed at users 14 to 16 years old, they implement an opt-in consent.)	PBJS should prevent header bidding activity from accessing the device.	PBJS should prevent header bidding activity from accessing the device.

Functional Requirements

The general structure of the feature is to establish:

• A convention for defining device access permissions
• Flexible configuration that allows multiple ways to define the access permissions
• Code mechanisms for enforcing the permissions

1. There must be a consent for device-access-and-storage that is comprised of:

• A default
• Array of overrides per-bidder (biddercode) and per-user-id-sub-module

2. The system must support setting device access permissions in the following ways:

   1. PBJS GDPR module should set turn the default consent flag if gdprApplies is true AND (there's no consent string OR standardPurposeConsents["1"] is false) [this will evolve with TCF2]
   2. The publisher must be able to set the device access permissions, both default and overrides. In doing so, the Pub must be able to refer to PBJS biddercodes, they should be able to refer to Vendor List IDs, and they should be able to define UserID sub-module overrides. The Pub should be able to set these permissions directly or via an event callback function.
   3. The publisher should be able to define the priority of the configuration:
      Default: User settings (i.e. GDPR consent string, COPPA flag) over publisher settings (e.g. setConfig)
      Publisher settings over user settings
   4. When the COPPA flag is set, the default should be suppress device access. The Publisher should be able to override this default.
   5. The GDPR module should be able parse the IAB consent string and set per-bidder overrides. The module should be able to map GVL ID to bidderCode.

3. The system must be able to enforce the device access permissions.

   1. Bid adapter modules may not set ID cookies or any kind of local state (e.g. dropping pixels) without using the usersync feature.
   2. PBJS should be able to enforce usersync functionalty based on global/per-bidder consent flag that was set above.
   3. PBJS UserId module must not call userid modules without device access as appropriate.
   4. PBJS getCookie() and setCookie() utils functions must only access the device when allowed
   5. PBJS *LocalStorage() utils functions must only access the device when allowed.

4. If a bidder or UserId module wants to be excluded from the rules, they must add a comment into the code and on their prebid.org documentation with a link to their privacy policy.

[benjaminclot]

@bretg 100% agree with this proposal, also thanks for taking it under serious consideration.
One question though: since cookie drops happen through the bidder endpoint (and they can be updated whenever), how would PBJS validate that GDPR is enforced? Will there be regular checks or is each SSP responsible for his own module?

[bretg]

This proposal implements a healthy skepticism on the front-side of the header bidding auction: usersync calls will not be made in the scenarios described above. If they are made, it's up to each vendor's end point to do the right thing.

PBJS cannot control whether a vendor tries to set storage when an ad is rendered.

[bretg]

Rubicon is offering to staff this one. @mkendall07 - this is probably a big enough change to consider making it a 4.0 because it could change monetization characteristics for pubs... there are settings they should be thinking about before releasing.

The sub-committee discussed releasing this feature with 3.x and defaulting to equivalent 'permissive' config, but we're leaning towards biting the bullet here and tightening sooner rather than later. The issue being that we're still putting out patches for 2.44.x. Worth discussing.

[bretg]

The PBJS committee met and agreed that this feature should be developed in the context of 3.x with default that don't change behavior. At some point (perhaps soon), we may decide to change the defaults with a 4.0.

FWIW - this item didn't make the cut for the current Rubicon sprint. If there's anyone else who can implement sooner, we're happy to review.

[patmmccann]

It seems there may be one more scenario to consider: California users under 16, which become opt in required instead of opt out like California adults.

[bretg]

PBJS doesn't know the age of the user. But point taken that the COPPA flag should take precedence.

[patmmccann]

My concern is that when a publisher knows they have content aimed at users 14 to 16 years old, they may wish for gdpr like controls to be in place on device access for California users rather than CCPA like controls. An article in adexchanger today reports that for teenagers not covered by COPPA in California, USP should default to opted-out rather than opted-in. This seems to have relevance to this issue.

…

On Mon, Jan 27, 2020 at 2:13 PM bretg ***@***.***> wrote: PBJS doesn't know the age of the user. But point taken that the COPPA flag should take precedence. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4747?email_source=notifications&email_token=AAM25ZYFM7OKTJQIKH2AUSTQ74W6DA5CNFSM4KIB23S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKAWLTQ#issuecomment-578905550>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM25ZYIZLLFQBBOS2FG6A3Q74W6DANCNFSM4KIB23SQ> .

[bretg]

Patrick - I think this scenario should be covered by the flexibility being required, but I added a specific row nonetheless.

[bretg]

I'm going to propose that we defer this effort -- instead of building it for TCF 1.1 when we're so close to it's end-of-life.

How about we instead implement as part of #4867 directly in TCF2.0 instead?

[patmmccann]

That unnerves me a bit given the genesis of the ticket this was based on. TCF 2.0 is IAB guidance, but this ticket stems from an actual government complaint.

…

On Tue, Feb 18, 2020 at 7:29 PM bretg ***@***.***> wrote: I'm going to propose that we defer this effort -- instead of building it for TCF 1.1 when we're so close to it's end-of-life. How about we instead implement as part of #4867 <#4867> directly in TCF2.0 instead? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4747?email_source=notifications&email_token=AAM25Z5TDPFMKW7M3BEZMHLRDR4ORA5CNFSM4KIB23S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF4HEY#issuecomment-587973523>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM25Z5GF4U6X4FNAMTNWPTRDR4ORANCNFSM4KIB23SQ> .

[benjaminclot]

My views on this are:

• modules should be tested regularly for basic GDPR compliance (i.e. at the least no device access when the consent is blank or purpose 1 refused (I think it's the same in TCF 1 & 2))
• any module found non-compliant should:
  • generate a ticket and its maintainer be notified
  • generate a warning in the docs

That way publishers and networks are being informed of possible legal problems without having to test things by themselves and can choose to include (or not) problematic modules.

[bretg]

We discussed in today's Prebid.js meeting and came up with a radically simpler (and quicker) approach, relying on the publisher to determine when to turn off device access and then configure:

1. turn off usersync (already supported with the syncEnabled flag)
2. turn off userId modules (just don't configure them)
3. turn off utils setCookie,getCookie,hasLocalStorage (new config option)
4. review to ensure that all modules are either using the core utils functions or paying attention to a new config option.

The proposed new config option is:

pbjs.setConfig({deviceAccess: false});

[benjaminclot]

Mmm... How do you see this working @bretg? Since Prebid.js is waiting for the CMP to get the consent string, wouldn't it be normal for Prebid.js to parse the response and apply the appropriate config? Otherwise I only see it delaying the bid requests even further.
Also, this doesn't fix bidders writing cookies (through the XHR requests) or to the LocalStorage (Criteo sideloads a script for example).

[patmmccann]

@benjaminclot, do you not see an urgent need to do something before TCF 2.0 consent string parsing and enforcement is developed? In the meeting today your comments on #4701 were mentioned reflecting the urgency of an interim solution.

…

On Wed, Feb 19, 2020 at 1:57 PM Benjamin Clot ***@***.***> wrote: Mmm... How do you see this working? Since Prebid.js is waiting for the CMP to get it the consent string, wouldn't it be normal for Prebid.js to parse the response and apply the appropriate config? Otherwise I only see it delaying the bid requests even further. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4747?email_source=notifications&email_token=AAM25ZZDADMRMFDMJOU6B6DRDV6JZA5CNFSM4KIB23S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMJBNWQ#issuecomment-588388058>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM25Z3W2ZQRP3ZBKH6YNC3RDV6JZANCNFSM4KIB23SQ> .

[benjaminclot]

@patmmccann interim yes, but useful. As described, the proposal is not very useful and doesn't rely on the user's choice. And it doesn't fix the endpoints writing cookies (even with usersync disabled) whatever the consent is, which is what the government agency is looking at: "no consent, are cookies being written?".

[bretg]

How do you see this working

Building full TCF-parsing capability in Prebid.js is going to take some time. At least weeks. In the meantime, we want to give publishers the ability to manage these scenarios.

The idea is that logic on the publisher's page determines "Purpose 1 consent needed but not granted", and takes the following actions:

1. does not enable the user ID modules
2. sets userSync.syncEnabled:false
3. sets deviceAccess:false

We will make sure that all modules (including criteo) Do The Right Thing when deviceAccess is false. They must either use the core storage utilities or read the deviceAccess config themselves.

As described, the proposal is not very useful and doesn't rely on the user's choice.

It does rely on the user's choice, but it's up to the publisher to parse that choice and set up Prebid appropriately.

wouldn't it be normal for Prebid.js to parse the response and apply the appropriate config?

We'll get there. But as you see from the PRD, TCF support is bigger than we understood. We've already lost a month since you opened the original issue, and need to provide a very short term workaround.

So - before Prebid.org goes and builds this rather complicated functionality into javascript, we really need feedback from publishers that it will be utilized. From this conversation, it appears to desired, but so far there's been no response from the pubs that are members of prebid.org.

The other strategic approach Prebid could take is to just suggest hooks for publishers to parse the strings on their own and implement callback functions to configure Prebid behavior. e.g. say the user rejects bidderA. There are four approaches:

1. Do nothing - trust bidderA's endpoint to parse and recognize that they need to no-bid
2. Leave it up to bidderA's adapter to parse and recognize that they need to no-bid
3. Have a super-smart TCF module fully supported by Prebid.org
4. Let each publisher implement their own logic and use a 'beforeBidRequest' callback to remove bidderA from AdUnits.

[benjaminclot]

First off, thanks to everyone involved in this project, I know it's hard to hear everyone's opinion while still trying to make things go forward and be fast and efficient in a post-GDPR world.

That being said, it's been almost two years, so I think it's time laws be enforced, not just because the IAB changed the TCF version. Also, the base subject kind of got sidetracked, with focus being made on userSync and having to parse the consent string client-side.
So let me re-focus this issue around this simple statement: no consent, no device access.

As of today, here is the situation:

1. purpose 1 in both TCF releases is basically the same: you have to get consent to access (read or write) the device
2. bidder modules, through their endpoints, basically ignore the consent status and write cookies -- this happens outside the purview of Prebid.js (I'm not talking about Prebid Server)
3. bidders can (and soon will have to, thanks to Google) work without cookies (they don't necessarily have to nobid if they don't have consent) -- e.g. AppNexus has had an option to buy cookieless users for years
4. userSync modules, when enabled, each have a mind of their own (pubCommonId doesn't read the consent string, DigiTrust reads the consent string but has consent to "true" by default, etc.)

This is why my previous proposal still stands, at almost no dev cost to Prebid.js core maintainers:

1. write and run daily tests with blank or purpose 1 refused consent strings that check each and every module (bidders, analytics, userSyncs) for device access (with ideally at least two consecutive bid requests, as some modules, like AppNexus', seem to write cookies starting with the second bid request 🤔)
2. flag modules found accessing the device (in the docs? in their source code? elsewhere?)
3. alert the modules' maintainers

Then you have two choices: either Prebid.js becomes a "cop", thus enforcing GDPR, and removes non-compliant modules (after a grace period?); or Prebid.js publishers, knowing fully well which modules are compliant or not, take their own responsibilities.
My point is that bidder endpoints have to be GDPR compliant and Prebid.js doesn't control them, but it can check that they behave as they should.

This solution, while being easy on the Prebid.js team, will ensure basic GDPR compliancy, hopefully in a short time.

PS: virtually no one blocks purpose 1 for a single bidder, so these tests can come at a later time.

[bretg]

I appreciate your thoughtful writeup @benjaminclot , but disagree with the statement "almost no dev cost to Prebid.js core maintainers". Becoming an automated and proactive "cop" or "auditor" is big change for Prebid and will come with dozens of hours of edge cases, debate, documentation, communication, coding, testing, and troubleshooting.

I personally agree that Prebid needs to head in this direction, but it will not be a quick transition. @mkendall07 may have a different view, but I stand by my short-term proposal and have asked a Rubicon Project engineer to build the deviceAccess flag. I'll draft a doc for prebid.org describing the workaround that pubs can implement before Prebid does the right thing.

And then we'll:

• resume discussing the TCF 2.0 proposal in https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit#
• begin wrapping our heads around automated validation, implications, and consequences. This is a board-level discussion.

[benjaminclot]

As I see things, the deviceAccess flag will sadly have no real use as it won't have any impact on how bidder endpoints behave. Setting it to false won't block anything unless they change how they operate, which would be the main fix. I don't understand why this is not being addressed.

As for our publisher and its upcoming audit, the only real solution for GDPR compliancy will be to wait for the consent string, parse it and in the absence of consent, don't retrieve ads... CMPs are now ad blockers 😞

[bretg]

Setting it to false won't block anything unless they change how they operate, which would be the main fix

I disagree with this.

When it comes to purpose 1, Prebid.js will enforce that the open source bid adapters are using the core cookie functions which will pay attention to the flag. As a result, they will not be able to set first party cookies if they shouldn't. We cannot prevent their endpoints from attempting to set 3rd party cookies.

I argue that this is an adequate near-term solution. If deviceAccess is set to false, there won't be any first party cookies.

You can already control usersyncs. You can already control userId modules.

What's missing? (at least in the context of Purpose 1)

[benjaminclot]

What's missing? (at least in the context of Purpose 1)

GDPR dooesn't make the distinction between 1st party and 3rd party cookies (nor does the French CNIL). No device access means no cookie (well, except for the consent one, obviously). At all. They don't expect half measures on this front and have clearly stated it.

[bretg]

I'm skeptical that any major vendor's endpoint is trying to set a 3rd party cookie on an auction request. Happy to be proven wrong. But if they are, we will have to address it case-by-base for now.

Setting up test pages that hit real end points for 250 bid adapters is going to be an unbelievable headache. I've tried this for just ~10 adapters in Prebid Server and it sucked... test params don't work, contacting the listed "maintainers" often results in bounced email or no response. And when it comes to the theory that auction endpoints are setting 3rd party cookies, how are we to know whether a no-bid or test params has the same behavior as a real bid params? Anyone who wanted to trick us would have no trouble doing so.

We will continue to discuss Prebid's role in policing the whole internet, but solving the first-party cookie problem is clearly something that we can do and perhaps should have done last year.

I would not bet that Prebid ever becomes a perfect auditor/cop. It's too easy to hack the auditor. (will try not to make a VW reference. oops, failed.) Each publisher should consult with their legal counsel to determine their course of action should a vendor be found attempting to set 3rd party cookies. One obvious remedy is to boot them from your auction until they clean up their act. That will get better action than a nag email from an open source group.

[benjaminclot]

I'm skeptical that any major vendor's endpoint is trying to set a 3rd party cookie on an auction request. Happy to be proven wrong. But if they are, we will have to address it case-by-base for now.

Just to prove my point, with Rubicon, on the fastlane endpoint in a private window and no consent, here is what happens:

We will continue to discuss Prebid's role in policing the whole internet, but solving the first-party cookie problem is clearly something that we can do and perhaps should have done last year.

Yes, this is a good first step.

It's too easy to hack the auditor

I agree, this will be tough.

[bretg]

Thanks. I've slacked you on AdOps to get some more details about what you're seeing with Rubicon.

[bretg]

Adding people whose modules are going to be affected by this effort: @loorke, @goosemanjack, @rcheptanariu, @pycnvr, @mizmaar3, @vgrigory, @jrosendahl

Your modules were making native JS calls to setcookie, getcookie, setlocalstorage, or getlocalstorage. This isn't allowed under certain scenarios, so they've all been changed to use the centralize functions in utils.js which will enforce the access rules.

The moules:

• adspendBidAdapter
• digitrustIdSystem
• invibesBidAdapter
• pubcommon.js (the deprecated pubcommon module)
• widespaceBidAdapter

[justinegreene]

At the request of @patmmccann adding a few thoughts here. If these should go elsewhere, please let me know.

Parrable, as an Identity provider, has a need to persist certain signals in our first party cookie and pass them to the publisher partners that are accessing our UserID module. Specifically, users can indicate an opt-out signal to IBA and CCPA through the NAI/DAA consumer choice and privacy tools and those choice. These essentially are signaling an opt-out through the identity provider, not the publisher... globally essentially. The implementations of IBA and CCPA may be different rom each other depending on the implementation of the service provider. With IBA, perhaps the ID is suppressed, or perhaps it is a signal that is passed to the bidder so that if the bidder is performing IBA they know not to. Parrable uses the latter. We does not require that the ID be suppressed only that the signal be present and respected. With respect to CCPA, we do suppress the ID, but we still pass the opt-out signal so that the bidder knows that the ID is not present because of consumer choice (useful statistically).

We have run into a few issues here:

1. The first was that getID only returns a single cookie, and to access multiple cookie we need to use direct cookie access rather than going through prebid storage, which seems to defeat the purpose of prebid storage. We solved this by moving to a compound cookie that we can deserialize to access the different keys. This is fine if all the other cookie related information is the same and synchronized, expiration date, same site, secure, etc.
2. We want to present the deserialized object to the bit adapter but the bid adapter expects that the UserID module is presenting a single string. This requires that the bid adapter have special handling for any userID modules that are not just presenting a string. Seems to defeat the purpose of having a defined interface. It would be more useful to provide an object that has defined fields and an extension object (like openRTB), so that a default handler could handle everything and there could be custom handler for extensions where needed. I would think that there is some basic information that a service provider (CCPA term) may want to pass through the publisher, to the bidder such as CCPA, IBA, COPPA, nabe GDPR and there should be a way to do this as prebid itself will have no knowledge of the service providers stored preferences, only the publisher stored preferences.
3. The third issue is versioning so that breaking changes can be introduced gracefully and older versions depreciated gracefully. If an object were being used, it could support multiple versions of the data, allowing a new version to be deployed in parallel with the current version then the current version removed when all the bid adapters were updated to use the new version.

Happy to engage in further discussion here or elsewhere. I think that these are important need for the user ID module interface. It needs to be a little more flexible.

[bretg]

@justinegreene -

the bid adapter expects that the UserID module is presenting a single string

Not correct. Each userID module is (and was) free to define its interface to bid adapters. Only digitrust took advantage of this.

Since only Conversant, Ozone, and Pubmatic are referring to parrableid, you would just need to work with the three of them to change your interface to an object. I would recommend just changing the code for them in a single PR and let them review. You're welcome to version the object if you wish.

I'm not sure if you're asking for permission to do your own setCookie without going through the central utils.js functions, but if you are, that will only be allowed with clear documentation in your user ID module indicating to publishers that you have requested an exception they need to be aware of.

[bretg]

Following up on the thread with @benjaminclot from above, did some digging and found that there is a change we should consider making. It's sorta separate from the device access piece, but is related to GDPR, so I'm proposing we discuss here.

1. Rubicon (and perhaps other bidders?) is not always doing IP address lookups to determine GDPR scope. So if the CMP doesn't load and an EU request goes out without the "&gdpr=1" flag, a cookie may be set.
2. Prebid.js could solve this problem allowing pubs to force the page into GDPR mode.

Proposal:

pbjs.setConfig({
    consentManagement: {
          gdpr: {
              cmpApi: 'iab',
              timeout: 8000,
              allowAuctionWithoutConsent: false,
              defaultGdprScope: true         // send gdprApplies: true to adapters when the CMP doesn't respond
            }
      }
});

Between this and manually turning off usersync, I think we'd be in better shape.

[pycnvr]

@bretg Thanks for the notification. The pubcommonId related changes in #4913 looks good. There is a small suggestion to prevent extraneous id generation, but given that userid module should be disabled whenever deviceAccess is switched off, it's more of a precaution.

[patmmccann]

The default scope flag would work well in our stack, great idea!

…

On Sun, Mar 1, 2020, 3:06 PM bretg ***@***.***> wrote: Following up on the thread with @benjaminclot <https://github.com/benjaminclot> from above, did some digging and found that there is a change we should consider making. It's sorta separate from the device access piece, but is related to GDPR, so I'm proposing we discuss here. 1. Rubicon (and perhaps other bidders?) is not always doing IP address lookups to determine GDPR scope. So if the CMP doesn't load and an EU request goes out without the "&gdpr=1" flag, a cookie may be set. 2. Prebid.js could solve this problem allowing pubs to force the page into GDPR mode. Proposal: pbjs.setConfig({ consentManagement: { gdpr: { cmpApi: 'iab', timeout: 8000, allowAuctionWithoutConsent: false, defaultGdprScope: true // always send gdprApplies: true to adapters } } }); Between this and manually turning off usersync, I think we'd be in better shape. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4747?email_source=notifications&email_token=AAM25Z3DXR4WYPIVIKH2V3LRFK55LA5CNFSM4KIB23S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNJK4Q#issuecomment-593139058>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM25Z6CD4FU4IEVBJN7EWLRFK55LANCNFSM4KIB23SQ> .

[bretg]

apparently there are a lot more adapters affected by this. Heads up to:

• adagio: @osazos, @nfo
• adkernel analytics: @ckbo3hrk
• criteo: @leonardlabat, @Spark-NF
• finteza analytics: @finteza
• kargo: @samuelhorwitz
• mantis: @parisholley
• mgid: @Gaudeamus
• nanoInteractive: @nanointeractive
• newborntownWeb: @z-sunshine
• orbidder: @RainerVolk4014
• pubwise analytics: @GLStephen
• realvu analytics: @tchibirev, @jrosendahl
• reload: @mafernandez80 , @hashedhyphen
• roxot analytics: @sergey-roxot , @mikhail-roxot
• sigmoid analytics: @sigmoidanalytics
• staq analytics: @mquirion
• trion: @grohm33

Please check the PR and confirm you're good with the changes we're making for you.

[samuelhorwitz]

This looks good from my end.

Edit: Actually, @bretg I was wondering, just to confirm, are these settings overridable per-adaptor by the publisher? I haven't followed the thread closely but the initial design at the top seems to indicate they are. However I'm just double checking if the changes made to our adapter will be configurable by the pub for our adaptor specifically, if desired.

[bretg]

@samuelhorwitz - this phase of the update isn't overridable per adapter. We're working on the full TCF2.0 support where flexible overrides will be available.

The assumption for this phase is that the page already knows the GDPR scope and has to parse the TCF string because header bidding isn't the only service that needs it. Since the page already knows this info it can Do The Right Thing:

1. set consentManagement.gdpr.defaultGdprScope
2. if the user hasn't consented to Purpose 1
   1. set deviceAccess: false
   2. don't enable usersync/userId modules
3. don't add bidders to AdUnits that don't support GDPR

[samuelhorwitz]

Thank you bret!

[mikhail-roxot]

This looks good for me Best regards, Mikhail Necheporenko CTO at Roxot 12 марта 2020 г., 18:05 +0300, Samuel Horwitz <notifications@github.com>, писал:

…

Thank you bret! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[bretg]

@benjaminclot - the PR for DeviceAccess is part of 3.12. See http://prebid.org/dev-docs/modules/consentManagement.html#page-control-of-consented-activities and http://prebid.org/dev-docs/publisher-api-reference.html#setConfig-deviceAccess

Unfortunately the defaultGdprScope feature didn't make 3.12 - should be available next week.

[bretg]

defaultGdprScope has been released with 3.13. Documented at http://prebid.org/dev-docs/modules/consentManagement.html

[madwant]

"PBJS should prevent header bidding activity from accessing the device."
"Header bidding activity" sounds broad - Does this mean: a) preventing bidders from dropping/updating cookies with the impression, b) preventing bid opportunities from being sent to bidders, or c) other?