"userSync" module initially calls "cookiesAreEnabled"

[renebaudisch]

Type of issue

Privacy - GDPR - Purpose One

Description

"userSync" module initially calls "cookiesAreEnabled" from the sessionManager and is writing and reading the device storage regardless of consent.

Steps to reproduce

I prepared a testpage where you can see that before the cmp is shown the LS get's written with cookieTest:
https://reports.asadcdn.com/demopages/2022/prebid.html

If it is too fast, set a breakpoint here:

Test page

https://reports.asadcdn.com/demopages/2022/prebid.html

Expected results

Not accessing cookies/LS before user interacted with cmp

Actual results

Writes test value cookieTest regardless to CMP.

Platform details

latest pbjs all platforms

Other information

For more information please read:
#8410
#8613

[dgirardi]

What is the desired behavior - storage should not be touched at all when there is not, or there might not be consent for it? (userId is not the only offender in that case)

Does it matter that a temporary "probe" cookie like this one is not personally identifiable data, and is to the best of my knowledge not protected by GPDR? are you using some auditing tool that is offended by this usage?

[renebaudisch]

Our company lawyers have been contacted because of this cookieTest and they therefore pleased us to get rid of it. So at least in Germany there seems to be the opinion in law that these probes also are protected by GDPR, as it is a third party ad technology and by that term not necessary to operate the page and so has to have device access consent aka purpose one, but I'm not a lawyer.

But it doesn't also seem logical to check for LS if the user disallows the usage of it.
Even if this would be fine by law, all further access would be protected by GDPR and so even it is accessible by test the vendors may not, so why check at all in first? Why not only check when needed to avoid being affected by a law?

[patmmccann]

category translation, brand exclusion, and fpd enrichment modules have similar behavior. We'll want to put this interpretation of the law [remove device access for storage items critical to basic function before consent] behind config

[dgirardi]

I agree that there's no need to check for storage if there is no consent, it's an accident that's what happens now, but there's a wider problem of doing without usage of storage that (so far) we thought was OK. I think we can fix the userId case by addressing that check and the storing of the consent string (which also bypasses GDPR, but I think it's just an optimization and not mandatory).

[dgirardi]

I believe the fix here is:

• remove the cookie probing logic, it should not be necessary because we already check navigator.cookieEnabled (this is also confirmed by the test page not actually setting a cookie, only localStorage)
• refactor userId moving the valid storage types logic to run when consent data is available; also make sure that it can work without the storing of consent data
• add a new config (consentManagement.alwaysRequireStorageConsent ? any better suggestion?) that would disable bypassing of enforcement even for "core" modules
• update the gdpr enforcement module to treat all "core" storage as vendorless (so that it checks for purpose 1 consent, but not vendor consent, similar to what was attempted in Gdpr Enforcement module and sharedId/pubCommonId modules: vendor consent should not be enforced for first-party-id modules #8448

There's also some testing to do at least for fpdEnrichments to see that it doesn't populate a bogus domain if consent was declined for cookies.

[renebaudisch]

Whatever solves the unconsented access is fine for me, and it sound like a plan.
I also just wanted to save you work but without that deep knowledge you have this seems to makes more work than it avoids.
Sorry for that. I'll stay quiet from now on. Thank you a lot in advance everybody.