remove check for legitimateInterest in GDPR consent processing

[jdwieland8282]

We would like to keep SharedIds permission set as minimal as possible. Purpose 1 is sufficient to write and read a cookie. However the GDPR validation code, borrowed from Magnite, checks for additional permissions specifically legitimateInterest. We should remove that check.

Current GDPR Permissions

{
   "887":{
      "id":887,
      "name":"Prebid.org",
      "purposes":[
         1
      ],
      "legIntPurposes":[
         
      ],
      "flexiblePurposes":[
         
      ],
      "specialPurposes":[
         
      ],
      "features":[
         
      ],
      "specialFeatures":[
         1
      ],
      "policyUrl":"https://docs.prebid.org/privacy.html",
      "cookieMaxAgeSeconds":31536000,
      "usesNonCookieAccess":false
   }
}

Sharedid should only check for purpose 1 and vendor 887

For background on this issue please see: #20 (comment)

[dmdabbs]

Wanted to call out that the Prebid privacy policy refers to legitimate interest basis to process for EEA users.

[dmdabbs]

Also want to suggest that since Prebid.org code is always under the control of the publisher (entire Prebid setup and this optional feature is configured by the publisher) that this code could also rely on the publisher's consent for Purpose 1 for performing the cookie operations. Prebid.org at no point makes independent processing decisions in this case.

[bjorn-lw]

Wanted to call out that the Prebid privacy policy refers to legitimate interest basis to process for EEA users.

Legitimate interest cannot be used for purpose 1. See Appendix A, Purpose 1 here for example: (Allowable Lawful Basis) https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/

[bjorn-lw]

@jdwieland8282 We are getting queries from customers about having shared id support enabled. What is the status here?

[jdwieland8282]

Our council has reviewed and decided that Sharedid's GDPR configuration is sufficient for what it does.

[jdwieland8282]

reviewed with Prebid council and concluded no additional permission is needed.

[ahansson86]

Hi,

There seems to be a fundamental misunderstanding of what combinations of consent and legitimate interests can be used within the TCF framework, which is what @bjorn-lw has been trying to raise.

As of right now, Shared ID is dependant on vendor 887 getting set under Vendor LIs in the consent string. However, Vendor LI can only ever be set if a vendor is also declaring Legitimate Interest purposes, which 887 doesn't, and also can't, as purpose 1 is consent only as per TCF. This means that any REAL consent string created by a CMP will never contain the right consent for Shared ID to actually set an ID.

Any tests made with a consent string that actually generate an ID seem to be a custom generated string that can never actually be created if a user gives consent via a CMP.

What is needed is to change so that Shared ID doesn't require Vendor LI to be set for 887 and only look at Vendor Consent as a requirement for generating an ID.

[dmdabbs]

I'd like to resurface my earlier suggestion that you consider not even using a vendor id, since Prebid is not a controller - AFAIK it makes no processing decisions independent of publishers who configure/control their properties' use of the SharedID service, right? The service needs ePrivacy consent to read/write the user's device (cookie/local storage) - TCF Purpose 1. The TCF has a publisher-level signal indicating whether the publisher has consent for all core Purposes. If Purpose 1 is consented and this publisher-level bit for Purpose 1 is consented, then the service can do its thing.

Having said that, using a vendor does provide means to maximise transparency, such as the option for Prebid to declare and publish a deviceDisclosure.json file at prebid.org.

[jdwieland8282]

Hi @dmdabbs our legal council has reviewed and signed off on our current approach. Also, we are setting a cookie when we access the device, I'm not sure how we get around not having a vendor id.

[ahansson86]

@jdwieland8282 I agree a vendor ID is needed and consent for purpose 1 as a cookie is set. However the current technical implementation is not valid from a TCF standpoint, so a change is required there to remove the check for Vendor LI for vendor 887.

[jdwieland8282]

apologies all, you are correct. We have this work on our internal development queue, its not quite at the top of that list yet but it will get done. If anyone else is interested in helping out please feel free to submit a PR, and assign to @SKOCHERI to review.

[thomas-netric]

PR submitted, didn't have permissions to assign it though. @SKOCHERI can you have a look at #23?

[SKOCHERI]

#23 is merged and deployed

[bretg]

@jdwieland8282 - can this be closed? Is there a PBJS impact?

[bretg]

Confirmed with @jdwieland8282 that this was released. There was no PBJS impact.

[hdeodhar]

Hi @SKOCHERI We are seeing an interesting behaviour in the EU which could suggest this hasn't resolved.

When we run this link that has sharedid implemented (after providing consent to all) we see a request going out to "https://id.sharedid.org/id" but the response is just an empty object { } (see screenshot attached)

Whereas when we run "https://id.sharedid.org/id?gdpr=1&gdpr_consent=CPDqN8EPDqN8EAGABCENBTCgAP_AAH_AABpYHAEL5CpMQCFAMWB8IookIQAXwBxQIWAQghABAQAAABAQIIwAAAAiAECAAAAAAQYAAFAAAAAAAAAAQEEAIAABAAEECAAAgAAAAAAAAAABQAAAABAAAAAAEAAABAAAAAAggAAAAAIAQEAAAAEAAAAAAAgEDgoGIACwAKgAXAAyAByAD4AQAA0AB9AEQARQAmABPACqAF8ANAAbQBCACOAEsAKUAWYAuQBfADKAHcAPYAfoBA4CDgIQARYAlIBYoC0ALSAX4A3gBxADqgIbAScAmIBMgC7QF3gLzAZIAywBpQDaAHAAOCAEGQAQExCIAQB1QENhoAQB1QENlIAIATwA.YAAAAAAAAAAA" for example where a consent string and gdpr=1 is hardcoded, we get a proper sharedid in the response. (see screenshot attached)

This behaviour suggests something is not right with the way sharedid service is supporting gdpr.

[thomas-netric]

@hdeodhar It looks like GDPR support was added in Prebid v4.26.0 (prebid/Prebid.js#6275).
Ladbible is running v4.25.0.

[hdeodhar]

Please ignore my comment. This is now working as expected! Thanks @thomas-netric I was actually testing with an upgraded pbjs version but realised I had implemented it incorrectly.