-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
adding PBS privacy FAQ entry #1931
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -77,18 +77,94 @@ creates or updates the `uids` cookie. | |
|
||
The most common source of requests for Prebid Server is from Prebid.js: | ||
|
||
0) Assume that the user doesn't have any cookies for the Prebid Server domain. | ||
1) User loads a page with Prebid.js that's going to call Prebid Server -- i.e. the pub has set up s2sConfig. | ||
2) Immediately after seeing that s2sConfig is setup, Prebid.js calls Prebid Server's `/cookie-sync` endpoint to initiate syncing | ||
3) Prebid Server sees there no `uids` cookie, so responds to the browser with a list of pixel syncs for bidders that need to be synced. | ||
4) Prebid.js places all of the pixels on the page, but in the meantime, also initiates the auction. | ||
5) Because the syncs haven't completed yet, the auction call to Prebid Server doesn't yet contain the uids cookie. | ||
6) The first auction happens without IDs | ||
7) At some point later, the pixels come back to Prebid Server through a /setuid redirect, setting (or updating) the `uids` cookie. | ||
8) The second page view will have the IDs available. | ||
1. Assume that the user doesn't have any cookies for the Prebid Server domain. | ||
1. User loads a page with Prebid.js that's going to call Prebid Server -- i.e. the pub has set up s2sConfig. | ||
1. Immediately after seeing that s2sConfig is setup, Prebid.js calls Prebid Server's `/cookie-sync` endpoint to initiate syncing | ||
1. Prebid Server sees there no `uids` cookie, so responds to the browser with a list of pixel syncs for bidders that need to be synced. | ||
1. Prebid.js places all of the pixels on the page, but in the meantime, also initiates the auction. | ||
1. Because the syncs haven't completed yet, the auction call to Prebid Server doesn't yet contain the uids cookie. | ||
1. The first auction happens without IDs | ||
1. At some point later, the pixels come back to Prebid Server through a /setuid redirect, setting (or updating) the `uids` cookie. | ||
1. The second page view will have the IDs available. | ||
|
||
There's a nuance here: the company that's hosting Prebid Server can configure it to read and utilize their exchange's | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be a note: Note: The company that's hosting Prebid Server can configure it to read and utilize their exchange's native cookie. i.e. if you're using Rubicon Project's Prebid Server, it can read their 'khaos' cookie, and if you're using AppNexus' Prebid Server, it can read their 'uuid2' cookie. If the host company is an exchange and the user has the exchange cookie, the host company will have an ID one page-view sooner than the other bidders. This gives a slight edge to the hosting company in some scenarios, but it's technically unavoidable and better for both buyers and sellers to have one ID available rather than zero. |
||
native cookie. i.e. if you're using Rubicon Project's Prebid Server, it can read their 'khaos' cookie, and if you're using | ||
AppNexus' Prebid Server, it can read their 'uuid2' cookie. In other words, if the host company is an exchange and the user | ||
has the exchange cookie, the host company will have an ID one page-view sooner than the other bidders. This gives a slight edge to | ||
the hosting company in some scenarios, but it's technically unavoidable and better for both buyers and sellers to have one ID available rather than zero. | ||
|
||
## How does Prebid Server support privay signals? | ||
|
||
### Mobile 'Limit Ad Tracking' flag | ||
|
||
If PBS receives 'device.lmt' flag in the OpenRTB request, it does the following anonymization: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesn't look like PBS-Go supports this. Added as a high priority item in our backlog. |
||
|
||
- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses | ||
- Removes user.id and user.buyeruid | ||
- Removes the request.device.ifa attribute | ||
- Rounds the request.device.geo. {lat,lon} to two decimal places | ||
|
||
### GDPR | ||
|
||
Prebid Server host companies and publishers have the ability to control the enforcement | ||
activities that take place. | ||
|
||
The enforcement strategy changed significantly between TCF 1.1 and TCF 2.0. [TCF2](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md) is a | ||
more nuanced and stricter policy. | ||
|
||
#### TCF 1.1 | ||
|
||
If Prebid Server determines that the user is in GDPR scope and doesn't consent | ||
to *all* of the vendor's 'purposes' as declared in the Global Vendor List, it 'anonymizes' | ||
the request to the adapters: | ||
|
||
- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We use the same logic for TCF 1.1 and CCPA. Same comments here as for that section: For PBS-Go, the user.id and request.device.ifa is not removed for GDPR. We only remove those for COPPA. We additionally remove request.device.didmd5, request.device.dpidsha1, request.device.dpidmd5, and request.device.dpidsha1, and also round user.geo in addition to device.geo. |
||
- Removes user.id and user.buyeruid | ||
- Removes the request.device.ifa attribute | ||
- Rounds the request.device.geo. {lat,lon} to two decimal places | ||
|
||
Full details are available [here](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/developers/PrebidServerJava_GDPR_Requirements.pdf). | ||
|
||
#### TCF 2.0 | ||
|
||
If Prebid server determines the user is in GDPR scope, then consent is independently tested | ||
for each 'Purpose' with different consequences for each: | ||
|
||
{: .table .table-bordered .table-striped } | ||
| TCF Purpose | Consequence of Not Obtaining Consent | | ||
| ----------- | ------------------------------------ | | ||
| 1 - Device Access | Prevents one or more usersync activities for one or more vendors. | | ||
| 2 - Basic Ads | May result in skipping one or more bid adapters in the auction. | | ||
| 4 - Personalized Ads | May result in removing the userIds before calling one or more bid adapters. | | ||
| 7 - Measure Ad Performance | May result in skipping one or more analytics adapters. | | ||
| Special Feature 1 - Use precise geolocation data | May result in rounding lat/long values and IP address before sending to server-side adapters. | | ||
|
||
{: .alert.alert-danger :} | ||
Note: Support for TCF purposes other than Device Access is still under development and is | ||
expected to be released in May 2020. | ||
|
||
More details are available [here](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit#). | ||
|
||
### COPPA | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. COPPA and CCPA are laws, we should refer to them as such. The word rule doesn't carry the same weight and gives the impression that these are optional or don't come with penalties. |
||
|
||
The [Children's Online Privacy Protection Act (COPPA)](https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule) is a rule in the US. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should provide minimal detail on what this law covers: The Children's Online Privacy Protection Act (COPPA) is a law in the US which imposes certain requirements on operators of websites or online services directed to children under 13 years of age, and on operators of other websites or online services that have actual knowledge that they are collecting personal information online from a child under 13 years of age. |
||
If `regs.coppa` is set to '1' on the OpenRTB request, the following anonymization actions take place before going to the adapters: | ||
|
||
- Removes all ID fields: device.ifa, device.macsha1, device.macmd5, device.dpidsha1, device.dpidmd5, device.didsha1, device.didmd5 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Confirmed PBS-Go behaves this way. We remove both user and device geo. |
||
- Truncate ip field - remove lowest 8 bits. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We describe the policy in bits here and in bytes in the other sections. Consider using bytes here as well for consistency. |
||
- Truncate ipv6 field - remove lowest 32 bits. | ||
- Remove geo.lat, geo.lon. geo.metro, geo.city, and geo.zip | ||
- Remove user.id, user.buyeruid, user.yob, and user.gender | ||
|
||
### CCPA / US-Privacy | ||
|
||
The [California Consumer Privacy Act](https://oag.ca.gov/privacy/ccpa) is another rule in the US. The IAB has generalized | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should just say: The California Consumer Privacy Act is a law in the US. though I think we should provide a minimal idea of what the law covers: The California Consumer Privacy Act is a law in the US. which covers consumer rights relating to the access to, deletion of, and sharing of personal information that is collected by businesses. |
||
this state-specific rule into a [US Privacy](https://iabtechlab.com/standards/ccpa/) compliance framework. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, should be law, not rule. |
||
If `regs.ext.us_privacy` is parsed to find that the user has opted-out of a "sale", | ||
the following anonymization steps are taken: | ||
|
||
- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this a typo? Mask take off the last byte... |
||
- Removes user.id and user.buyeruid | ||
- Removes the request.device.ifa attribute | ||
- Rounds the request.device.geo. {lat,lon} to two decimal places | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Step 1 should be removed as it's not actually a step. I could be wrong but it sounds like a scenario description. I made a few tweaks to the rest of the content:
The most common source of requests for Prebid Server is from Prebid.js in a scenario where the user doesn't have any cookies for the Prebid Server domain.
1. The user loads a page with Prebid.js that's going to call Prebid Server -- i.e. the pub has set up s2sConfig.
2. Immediately after confirming that s2sConfig is setup, Prebid.js calls Prebid Server's /cookie-sync endpoint to initiate syncing
3. Prebid Server determines there are no uids cookie and responds to the browser with a list of pixel syncs for bidders that need to be synced.
4. Prebid.js places all of the pixels on the page and initiates the auction.
5. Because the syncs haven't completed, the auction call to Prebid Server will not contain the uids cookie.
6. The first auction occurs without IDs
7. At some point later, the pixels come back to Prebid Server through a /setuid redirect, setting (or updating) the uids cookie.
8. The second page view will have the IDs available.
On #3 - Prebid Server determines there are no uids cookie - is uids an acronym or var name or is it uid cookies? If uids is correct then it should read:
Prebid Server determines there is no uids cookie
or
Prebid Server determines there are no uids cookies