Skip to content
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

Core & multiple modules: strict purpose 1 consent option; do not require vendor consent for "core" storage / ID modules #8661

Merged
merged 10 commits into from
Jul 28, 2022

Conversation

dgirardi
Copy link
Collaborator

@dgirardi dgirardi commented Jul 7, 2022

Type of change

  • Bugfix

Description of change

This change:

  • makes it so that setConfig({deviceAccess: false}) always turns off all storage, including "core" storage (which currently ignores that flag, contrary to what the documentation says
  • introduces "vendorless" GDPR enforcement for pubCommonId/sharedId (same intent as in Gdpr Enforcement module and sharedId/pubCommonId modules: vendor consent should not be enforced for first-party-id modules #8448, which was later reverted)
  • introduces a new config option, setConfig({consentManagement: {strictStorageEnforcement: true}}), that - if set - forces all storage, including "core" storage, to respect consent; core storage would follow the same rule as "vendorless" modules (just generic P1 consent required), the rest would continue to respect both purpose and vendor as it does now
  • refactors userSync.js and the userId module to access storage only once consent data is available, so that the above can work
  • attempts to always enforce GDPR if the consentManagement module is installed (to try and catch gdpr-protected operations that happen before consent data is resolved).

As mentioned in #8651, there are a few other consumers of getCoreStorageManager - I only checked that fpdEnrichment would fail gracefully without storage. The rest (categoryTranslation and adpod.brandCategoryExclusion) may still be accessing storage before consent is resolved.

Other information

Closes #8651
Documentation: prebid/prebid.github.io#3889

// modules for which vendor consent is not needed (see https://github.com/prebid/Prebid.js/issues/8161)
const VENDORLESS_MODULES = new Set([
'sharedId',
'pubCommonId'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/prebid/Prebid.js/blob/master/modules/pubProvidedIdSystem.js also doesnt need consent but doesn't use device storage. Should it be on this list?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does look like it should, but now I'm wondering, aren't all 3 doing the same thing? should we think about removing some at some point?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the second one is definitely redundant and removing it is in the 8.0 proposal. PPID module is different, it allows a publisher to set any arbitrary id and also say what it is. It isn't very popular, but it would allow a publisher to say pass hash(login) or some other identifier that was quite different than the one used by sharedid / pubcommonid

@dgirardi
Copy link
Collaborator Author

dgirardi commented Jul 8, 2022

@patmmccann in drafting the docs for this, I noticed that what we say now:

You can prevent Prebid.js from reading or writing cookies or HTML localstorage by setting [deviceAccess: false]

Is not true; "core" storage, used as outlined above, still has access to the device regardless of that flag. Was this an oversight - should we fix it, or still require "true" disablers to also set alwaysEnforceDeviceAccess? (it could, conceivably, break users of category exclusion / translation, and change the domain set by fpdEnrichment).

@dgirardi
Copy link
Collaborator Author

dgirardi commented Jul 8, 2022

After discussing with @patmmccann and @bretg , we agreed on the following:

  1. a vendor (bid adapter, module) wants to read/store something. In GDPR scope, requires general P1 consent and vendor-specific consent. Requires deviceAccess flag. bid adapters also require bidderSettings.storageAllowed. (no changes)
  2. a "vendorless" ID module wants to read/store something. In GDPR scope, require general P1 consent. Require deviceAccess flag. (no changes)
  3. a "PBJS core" service or "vendorless module" wants to read/store something. Require deviceAccess flag (change! may break domain calculation) If consentManagement.strictStorageEnforcement is true, and in GDPR scope, requires general P1 consent (change, but safe because it's behind a new config flag)

the change for case 3 should be documented (coming soon!)

…ehind `consentManagement.strictStorageEnforcement`
@dgirardi dgirardi added needs 2nd review Core module updates require two approvals from the core team bugfix labels Jul 8, 2022
@ChrisHuie ChrisHuie self-requested a review July 11, 2022 18:27
@ChrisHuie ChrisHuie self-assigned this Jul 11, 2022
@ChrisHuie ChrisHuie removed their request for review July 12, 2022 13:07
@ChrisHuie ChrisHuie removed their assignment Jul 12, 2022
@ChrisHuie ChrisHuie requested a review from Rothalack July 12, 2022 13:07
@patmmccann patmmccann added feature and removed bugfix labels Jul 12, 2022
@patmmccann patmmccann changed the title Core & multiple modules: always enforce purpose 1 consent; do not require vendor consent for "core" storage / ID modules Core & multiple modules: strict purpose 1 consent option; do not require vendor consent for "core" storage / ID modules Jul 12, 2022
@patmmccann patmmccann removed the request for review from Rothalack July 25, 2022 16:50
Copy link
Collaborator

@osazos osazos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@patmmccann patmmccann merged commit 5812357 into prebid:master Jul 28, 2022
JacobKlein26 pushed a commit to nextmillenniummedia/Prebid.js that referenced this pull request Feb 9, 2023
…ire vendor consent for "core" storage / ID modules (prebid#8661)

* Allow sharedId to work without vendor consent

* Remove superfluous enforcement check from ixBidAdapter

* Make core storage respect device access rules

* respect storage access enforcement in userSync.js

* UserID: check whether storage is enabled only once consent can be enforced

* Add pubProvidedId

* GDPR enforcement: enforce consent when data is not available, but GDPR module is enabled

* Always enforce deviceAccess; move vendorless storage P1 enforcement behind `consentManagement.strictStorageEnforcement`
jorgeluisrocha pushed a commit to jwplayer/Prebid.js that referenced this pull request May 23, 2023
…ire vendor consent for "core" storage / ID modules (prebid#8661)

* Allow sharedId to work without vendor consent

* Remove superfluous enforcement check from ixBidAdapter

* Make core storage respect device access rules

* respect storage access enforcement in userSync.js

* UserID: check whether storage is enabled only once consent can be enforced

* Add pubProvidedId

* GDPR enforcement: enforce consent when data is not available, but GDPR module is enabled

* Always enforce deviceAccess; move vendorless storage P1 enforcement behind `consentManagement.strictStorageEnforcement`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature needs 2nd review Core module updates require two approvals from the core team
Projects
None yet
6 participants