as-ideas / oil

191 stars 56 forks source link

getVendorConsents called too soon #266

Closed mindplay-dk closed 3 years ago

mindplay-dk commented 5 years ago

Just for testing, I pasted this into the console on your sandbox page:

__cmp("getVendorConsents", {}, (data, success) => console.log({data, success}));

The callback gets immediately invoked, while the consent dialog is still open and no cookie has been set, and the supplied object has all 5 standard purposeConsents all set to false.

I believe this is incorrect according to the API spec, which states:

The vendorIds array contains the vendor ids (as identified in the Global Vendor List) for which consent is being requested. If vendorIds is null or empty, the operation will return consent status for all vendors in the vendor list. The callback function will be called with a VendorConsents object as the parameter. If vendorIds is provided and not empty, then VendorConsents.vendorConsents will only included IDs from vendorIds. The callback is called only after consent is obtained from the UI or existing cookies. The consent will be returned false ("No Consent") for any invalid vendorId. The boolean success parameter passed to the callback indicates whether the call to getVendorConsents() was successful.

The specification makes sense to me on this point: if the user has neither consented, nor indicated non-consent, we don't in fact know the consent state at all yet - it has to be established first, by some form of user interaction with the UI.

In accordance with the spec, invoking my callback with vendorConsents all set to false indicates the user has denied consent to all cookie purposes.

That's very different from merely not knowing yet.

I've seen other cookie consent scripts apparently making the same mistake, and I've seen people working around this by polling via calls to setTimeout() or setInterval() and actively waiting for consent - which may never come, and some scripts even give up after some number of attempts. But according to the spec, you're supposed to be able to ask once and get a reply when a reply becomes available.

If I wanted to, say, load non-targeted ads after the CMP script has loaded an initialized, I could use the ping command to achieve that - e.g. queue calls to ping and getVendorConsents, one of them clearing (or setting) a flag in the parent scope of my two callbacks; without any unnecessary delays from polling.

So I think the spec is right on this point and everyone is just implementing it wrong? 🤨

mindplay-dk commented 5 years ago

For reference, here's a page that correctly implements the API:

https://www.consentmanager.net/features.php

Try pasting the line from my post above, into the console, for comparison.

You'll see it does not execute the callback right away - not until you answer the consent dialog.

I believe this is correct according to the TCF spec.

mindplay-dk commented 5 years ago

I can now also confirm that the AppNexus Reference CMP implementation behaves as expected.

mindplay-dk commented 5 years ago

@ltparis2018 @Waschnick looks like you're the primary maintainers? would you like to comment?

I may be able to help, but I need someone to acknowledge the problem.

mindplay-dk commented 5 years ago

Can confirm that QuantCast CMP also behaves as expected.

mindplay-dk commented 3 years ago

@rbuer Closing all issues without comment? It might be easier to just turn off the issues tab altogether. You could also just mark the project as archived, since I understand from the README it's dead - that might have been useful, if someone wanted to fork the project, being able to see the issues that were left unresolved...