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.

Sign up for GitHub

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

Jump to bottom

gdprEnforcement: adding Purpose 2 #2061

Merged
merged 4 commits into from
Jul 23, 2020
Merged

gdprEnforcement: adding Purpose 2 #2061

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e268c6c
gdprEnforcement: adding Purpose 2
bretg Jun 16, 2020
a95b61c
minor edits
jeanstemp Jun 23, 2020
046a57e
edits
bretg Jun 30, 2020
d5b07aa
Update gdprEnforcement.md
jeanstemp Jul 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 47 additions & 59 deletions dev-docs/modules/gdprEnforcement.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,29 +16,30 @@ sidebarType : 1
{: toc }

{: .alert.alert-warning :}
This module requires the [EU GDPR consent management module](/dev-docs/modules/consentManagement.html), which reads consent values from the Consent Management Platform (CMP). The GDPR enforcement module
will then enforce the results. See the base module page for general background, usage, and legal disclaimers.
This module requires the [EU GDPR consent management module](/dev-docs/modules/consentManagement.html) (the base consent module), which reads consent values from the Consent Management Platform (CMP). The GDPR Enforcement Module
will then enforce the results. See the [base module page](/dev-docs/modules/consentManagement.html) for general background, usage, and legal disclaimers.

## Overview

The base [EU GDPR consent management module](/dev-docs/modules/consentManagement.html) performs the following actions:
The [base consent module](/dev-docs/modules/consentManagement.html) performs the following actions:

1. Fetch the user's GDPR consent data from the CMP.
2. Incorporate this data into the auction objects for adapters to collect.
1. Fetches the user's GDPR consent data from the CMP.
2. Incorporates this data into the auction objects for adapters to collect.

This GDPR enforcement module adds the following:
The GDPR Enforcement Module adds the following:

3. Allows the page to define which activities should be enforced at the Prebid.js level.
4. Actively enforces those activities based on user consent data.

The following table details the Prebid.js activities that fall under the [Transparency and Consent Framework (TCF)](https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/) scope:

{: .table .table-bordered .table-striped }
| TCF Purpose | In-Scope Activity | Enforcement Activity | Optional Controls |
| In-Scope Activity | TCF Legal Basis Required | Enforcement Activity | Prebid.js Version |
| --- | --- | --- | --- |
| Purpose 1 - Store and/or access information on a device | usersync pixels | May prevent one or more vendor usersyncs. | Do not enforce Purpose 1. Do not enforce Purpose 1 vendor signals. Do not enforce Purpose 1 for vendor V. |
| Purpose 1 - Store and/or access information on a device | user ID modules | May prevent one or more UserID modules from activating. | Do not enforce Purpose 1. Do not enforce Purpose 1 vendor signals. Do not enforce Purpose 1 for vendor V. |
| Purpose 1 - Store and/or access information on a device | device storage | May prevent one or more adapters or modules from being able to read or write cookies or localstorage in the user's browser. | Do not enforce Purpose 1. Do not enforce Purpose 1 vendor signals. Do not enforce Purpose 1 for vendor V. |
| Invoke usersync pixels | Purpose 1 - Store and/or access information on a device | May prevent one or more vendor usersyncs. | 3.14+ |
| Invoke user ID modules | Purpose 1 - Store and/or access information on a device | May prevent one or more UserID modules from activating. | 3.14+ |
| Read and write data to device | Purpose 1 - Store and/or access information on a device | May prevent one or more adapters or modules from being able to read or write cookies or localstorage in the user's browser. | 3.14+ |
| Perform header bidding auction | Purpose 2 - Basic ads | May prevent one or more bid adapters from participating in the auction. | 4.0+ |

There are plans to add more TCF Purposes and activities in future releases.

Expand All @@ -49,115 +50,101 @@ A page needs to define configuration rules about how Prebid.js should enforce ea
{: .alert.alert-warning :}
**Important Legal Note:** Prebid.org cannot provide legal advice about GDPR or any other governmental regulation. Our aim is to provide a toolkit of functionality that will let publishers configure header bidding as defined by their legal counsel. We will consider feature suggestions, and review any code offered by the community.

These are the fields related to GDPR enforcment that are supported in the [`consentManagement.gdpr`](/dev-docs/modules/consentManagement.html) object:
{: .alert.alert-info :}
To turn on Prebid.js enforcement you must:
1) Include the gdprEnforcement module in the Prebid.js build
and 2) setConfig `consentManagement.gdpr.cmp` to either 'iab' or 'static'

The following fields related to GDPR enforcement are supported in the [`consentManagement.gdpr`](/dev-docs/modules/consentManagement.html) object:

{: .table .table-bordered .table-striped }
| Param | Type | Description | Example |
| --- | --- | --- | --- |
| gdpr.rules | `Array of Objects` | Lets the publisher override the default behavior. | |
| gdpr.rules[].purpose | `String` | The only currently supported value is "storage", corresponding to TCF Purpose 1. | "storage" |
| gdpr.rules[].enforcePurpose | `Boolean` | Determines whether to enforce the purpose consent or not. The default in Prebid.js 3.x is not to enforce purposes. The plan for Prebid.js 4.0 is to enforce consent for Purpose 1 and no others. | true |
| gdpr.rules[].enforceVendor | `Boolean` | Determines whether to enforce vendor signals for this purpose or not. The default in Prebid.js 3.x is not to enforce vendor signals. The plan for Prebid.js 4.0 to enforce signals for Purpose 1 and no others. | true |
| gdpr.rules[].purpose | `String` | Supported values: "storage" (Purpose 1), "basicAds" (Purpose 2) | "storage" |
| gdpr.rules[].enforcePurpose | `Boolean` | Determines whether to enforce the purpose consent. The default in Prebid.js 3.x is not to enforce purposes. Prebid.js 4.0 enforces legal basis for Purposes 1 and 2 by default. | true |
| gdpr.rules[].enforceVendor | `Boolean` | Determines whether to enforce vendor signals for this purpose. The default in Prebid.js 3.x is not to enforce vendor signals. Prebid.js 4.0 enforces legal basis for Purposes 1 and 2 by default. | true |
| gdpr.rules[].vendorExceptions | `Array of Strings` | Defines a list of biddercodes or module names that are exempt from the enforcement of this Purpose. | ["bidderA", "userID-module-B"] |

Note:

- The vendorExceptions list is based on Prebid.js biddercodes instead of Global Vendor List (GVL) IDs, i.e. "rubicon" instead of "52". This was done to accomodate Prebid.js modules and adapters that don't have GVL IDs.
- To accomodate Prebid.js modules and adapters that don't have GVL IDs, the vendorExceptions list is based on Prebid.js biddercodes instead of Global Vendor List (GVL) IDs (i.e. "rubicon" instead of "52").

### Examples

The following examples cover a range of use cases and how Prebid.js supports
The following examples cover a range of use cases and show how Prebid.js supports
configuration of different business rules.

1) Enforce that the user consents to DeviceAccess as an activity and consider their per-vendor selection.
1) Enforce device access activity and basic ads. These are the default values (in Prebid.js 4.0) if the module is included in the build.

```
pbjs.setConfig({
consentManagement: {
gdpr: {
...
rules: [{
cmpApi: 'iab', // activates the enforcement module
defaultGdprScope: true,
rules: [{ // these are the default values
purpose: "storage",
enforcePurpose: true,
enforceVendor: true
},{
purpose: "basicAds",
enforcePurpose: true,
enforceVendor: true
}]
}
}
});
```

2) Enforce that the user consents to DeviceAccess as an activity and consider their per-vendor selection. However, BidderA is a special case - the publisher has entrusted BidderA for this activity.
2) Enforce that the user consents to DeviceAccess as an activity and consider their per-vendor selection. However, idSystemA is a special case - the publisher has confirmed that this system obtains a user ID every auction and does not write to the local device.

...
rules: [{
purpose: "storage",
enforcePurpose: true,
enforceVendor: true,
vendorExceptions: ["bidderA"]
vendorExceptions: ["idSystemA"]
Copy link
Contributor

Choose a reason for hiding this comment

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

The note above says we don't use IDs. So I find making this an "id" kind of confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The note says we don't use GVL IDs. Yeah, too many uses of the phrase "ID", but I don't see a way around this. I tweaked the example text to note "User ID"

Copy link
Contributor

Choose a reason for hiding this comment

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

better, thanks

}]

3) Enforce that the user consents to DeviceAccess as an activity, but don't consider their per-vendor selection.
3) Enforce legal basis for both storage and basicAds, with the exception of "firstPartyBidder", which is always allowed to run an auction. Assumes the publisher has special legal basis for this entity.

...
rules: [{
purpose: "storage",
enforcePurpose: true,
enforceVendor: false,
}]

4) Enforce that the user consents to DeviceAccess as an activity, but don't consider their per-vendor selection. BidderA is entrusted to enforce the rules on their own.

...
rules: [{
purpose: "storage",
enforcePurpose: true,
enforceVendor: false,
vendorExceptions: ["bidderA"]
}]

5) Turn off enforcement of Purpose 1: don't enforce either the user's DeviceAccess consent or their per-vendor selection.

...
rules: [{
purpose: "storage",
enforcePurpose: false,
enforceVendor: false
}]

6) Don't enforce the user's DeviceAccess consent, but do consider their per-vendor selection.

...
rules: [{
purpose: "storage",
enforcePurpose: false,
enforceVendor: true
},{
purpose: "basicAds",
enforcePurpose: true,
enforceVendor: true,
vendorExceptions: ["firstPartyBidder"]
}]

7) Don't enforce the user's DeviceAccess consent, but do consider their per-vendor selection except for BidderA.
4) Turn off enforcement of Purpose 1: don't enforce either the user's DeviceAccess consent or their per-vendor selection.
bretg marked this conversation as resolved.
Show resolved Hide resolved

...
rules: [{
purpose: "storage",
enforcePurpose: false,
enforceVendor: true,
vendorExceptions: ["bidderA"]
enforceVendor: false
}]

## Basic Enforcement

Prebid.js does not have access to the Global Vendor List (GVL), so it implements
a "basic" form of TCF validation using the supplied consent string.
a "basic" form of TCF 'legal basis' validation using the supplied consent string.

A goal of basic enforcement is to confirm that there's enough evidence of consent to pass data on to vendors who do have access to the GVL and can fully parse and enforce.

Before allowing an activity tied to a TCF-protected Purpose for a given vendor, one of these scenarios must be true:

- Configuration rules enforce both consent and vendor signals and either:
- we have the user’s purpose consent and the user’s vendor consent, or
- (for Purpose 2 only) we've confirmed the user’s LI (Legitimate Interest) Transparency is established for this purpose
- Prebid.js has the user’s purpose consent and the user’s vendor consent, or
- (for Purpose 2 only) we've confirmed the user’s Legitimate Interest (LI) Transparency is established for this purpose
- Configuration rules enforce only purpose consent and either:
- we have the user’s purpose consent, or
- (for Purpose only) we confirmed the user’s LI Transparency is established for this purpose.
- Prebid.js has the user’s purpose consent, or
- (for Purpose 2 only) we confirmed the user’s LI Transparency is established for this purpose.
- Configuration rules enforce only vendor signals and we have the user’s vendor consent
- Configuration rules enforce neither purpose consent nor vendor signal.

Expand All @@ -176,4 +163,5 @@ You can also use the [Prebid.js Download](/download.html) page.
## Further Reading

- [EU GDPR Consent Management Module](/dev-docs/modules/consentManagement.html)
- [IAB TCF Consent String Format](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md)
- [IAB TCF2 Consent String Format](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md)
- [Prebid TCF2 Support](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit#)
bretg marked this conversation as resolved.
Show resolved Hide resolved