Core & multiple modules: strict purpose 1 consent option; do not require vendor consent for "core" storage / ID modules #8661
Conversation
modules/gdprEnforcement.js
Outdated
| // modules for which vendor consent is not needed (see https://github.com/prebid/Prebid.js/issues/8161) | ||
| const VENDORLESS_MODULES = new Set([ | ||
| 'sharedId', | ||
| 'pubCommonId' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
|
@patmmccann in drafting the docs for this, I noticed that what we say now:
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 |
|
After discussing with @patmmccann and @bretg , we agreed on the following:
the change for case 3 should be documented (coming soon!) |
…ehind `consentManagement.strictStorageEnforcement`
dgirardi
added
needs 2nd review
patmmccann
changed the title
…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`
…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`
Type of change
Description of change
This change:
setConfig({deviceAccess: false})always turns off all storage, including "core" storage (which currently ignores that flag, contrary to what the documentation sayssetConfig({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 nowuserSync.jsand the userId module to access storage only once consent data is available, so that the above can workAs mentioned in #8651, there are a few other consumers of
getCoreStorageManager- I only checked thatfpdEnrichmentwould 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