Propose a GPC extension to OpenRTB #99
Conversation
|
Resolved the open comment. Mistake on my part. Let me know if there are any other questions. |
|
|
||
| #### Notes | ||
|
|
||
| See [the Global Privacy Control website](https://globalprivacycontrol.org/) for deatils on the specification and its current market support. |
|
|
||
| The goal is to support passing the Global Privacy Control signal to downstream participants in order to allow them to make decisions on how to interpret the privacy state of a user in regard to applicable regulations. | ||
|
|
||
| Downstream consumers of this signal should use it as the primary signal where they believe it applies, since not all publishers may use the signal to change their interpretation of other privacy signals or may interpret it the same way as a downstream consumer. So, where the downstream consumer of OpenRTB signals sees both a USPAPI signal and a GPC signal on a request and considers the GPC signal to mean an opt-out in California, and where the USPAPI signal does not indicate such an opt-out, then the downstream consumer should consider the user opted-out. |
There was a problem hiding this comment.
While this may be true, I'm not sure it's the appropriate place to state it
There was a problem hiding this comment.
@patmmccann Is there a better place to open up such a discussion?
There was a problem hiding this comment.
I'm not sure, but this looks like legal advice to me
There was a problem hiding this comment.
+1 I expect we have to strike this paragraph. I recommend following the pattern for our solutions to other regulations, e.g., https://github.com/InteractiveAdvertisingBureau/USPrivacy/blob/master/CCPA/US%20Privacy%20String.md.
There was a problem hiding this comment.
...should use it as the primary signal...
Is this dictate appropriate? What does "primary signal" mean? @wittjill's earlier suggestion we scope our purpose to facilitation was spot on
Can we change the two intro paragraphs so that it is more in line with how other privacy specs are written, something like:
This community extension supports passing the Global Privacy Control signal to downstream participants in order to allow them to make decisions on how to interpret the privacy state of a user in regard to applicable regulations.
For more information about the Global Privacy Control specification visit: https://globalprivacycontrol.org/
I'd propose this further minimalisation:
This community extension supports passing the Global Privacy Control signal that downstream recipients may use to determine how to process the request.
For more information about the Global Privacy Control specification visit: https://globalprivacycontrol.org/
If the detailed guidance is retained, "...USPAPI signal and a GPC..." is dated since USPAPI is deprecated in favor of GPP, yes?
details was misspelled once and then we all copied it. Fixed them all.
|
Resolved the minor edits @patmmccann Not sure what to do about the question of what an extension is intended to do / be used and where that should go? Is it that the detail is too high? Should it go somewhere else? I'm unclear on what the best place to put something like this is, but surely it needs to be someplace right? |
|
I am not sure what the best forum to discuss this is, but I feel confident this is not it. Perhaps: https://github.com/InteractiveAdvertisingBureau/USPrivacy/blob/master/CCPA/USP%20API.md |
|
@AramZS you can email me directly ([email protected]) and I can put you in touch with the privacy working groups. |
There was a problem hiding this comment.
Can we change the two intro paragraphs so that it is more in line with how other privacy specs are written, something like:
This community extension supports passing the Global Privacy Control signal to downstream participants in order to allow them to make decisions on how to interpret the privacy state of a user in regard to applicable regulations.
For more information about the Global Privacy Control specification visit: https://globalprivacycontrol.org/
|
|
|
Since the GDPR and US Privacy signals are being promoted to the main specification in OpenRTB 2.6, I recommend we do the same for this one. |
| <th>Description</th> | ||
| </tr> | ||
| <tr> | ||
| <td>regs.ext.gpc</td> |
There was a problem hiding this comment.
If this is needed at all (and I expect it is), I recommend we put it directly in the mainline specification next to the fields for GDPR, GPP, etc.
There was a problem hiding this comment.
Ignore my previous comment. I raised with the Working Group, the consensus is to stick with the extension for now.
|
Putting the prebid link that was on #98 here too Prebid implemented this on regs.ext.gpc |
| </tr> | ||
| <tr> | ||
| <td>regs.ext.gpc</td> | ||
| <td>integer</td> |
There was a problem hiding this comment.
Make string, and propagate the contents of the HTTP header as-is. Then there is no interpretation of the (originally, string) value as it passes down the chain.
|
Closing as dupe of #123 |
Intended to address #98
This is intended to apply to any applicable RTB version and I'd be happy to add to this PR if needed to allow it to apply to other iterations if maintainers will tell me what needs to be done in order to do so. I do not believe my organization is currently a Tech Lab member, however, if there are any questions I'd be glad to speak to the group.
The goal is to support passing the Global Privacy Control signal to downstream participants in order to allow them to make decisions on how to interpret the privacy state of a user in regard to applicable regulations.
Downstream consumers of this signal should use it as the primary signal where they believe it applies, since not all publishers may use the signal to change their interpretation of other privacy signals or may interpret it the same way as a downstream consumer. So, where the downstream consumer of OpenRTB signals sees both a USPAPI signal and a GPC signal on a request and considers the GPC signal to mean an opt-out in California, and where the USPAPI signal does not indicate such an opt-out, then the downstream consumer should consider the user opted-out.
When the creator of the OpenRTB object sees a GPC signal they must set this extension with that signal.